Ian & Stuart's Australian Mac 1993 September

home *** CD-ROM | disk | FTP | other *** search

/ Ian & Stuart's Australian Mac 1993 September / September 93.iso / Community / BBS / BBS Networks / Fidonet / Fidonet Basics < prev next >

Wrap

Text File | 1991-11-23 | 59.4 KB | 1,212 lines | [TEXT/R*ch]

-1- BASICS.TXT -- A tutorial for newcomers and prospective members of Rev. 0.3 FidoNet. (All those things they don't tell you about in the software docs!) Please circulate and post for D/L and File Request as BASICSXX.ZIP, where XX is the revision number (in this case, BASICS03.ZIP). TABLE of CONTENTS Basic FidoNet Terminology ...................... 2 FidoNet Technical Standards .................... 5 Fido News ...................................... 5 FidoNet Policy ................................. 6 More FidoNet Terminology ....................... 6 Events & Nodelists ............................. 6 Processing Nodelists ........................ 8 Nodelist Contents .............................. 8 File Requests, Attaches, etc. .................. 10 Routing Mail ................................... 11 EchoMail, How It Works ......................... 11 Cross-Links .................................... 15 Mail Archving & Naming Techniques .............. 17 How to apply for a Fido node number ............ 20 Security Issues and Passwords .................. 21 INDEX (copr 1990/1991) Chris Anderson at The Dinosaur Board Please refer all change requests to FidoNet 1:104/114 via NetMail. Some portions of this document are extracts from 101WAYS, which includes 101CRASH and 101NIGHT, (copr 1989), Chris Anderson. -2- First, get some basic FIDO terminology under your belt. These words will be used OFTEN during your use of any mailer and BBS net software! NETMAIL The international system of Electronic Mail. Designed primarily to transfer E-Mail messages between individual users around the world. The user sends his message from a local system and this message is forwarded to the appropriate system automatically. The sending system pays for the service by placing the outbound call, usually billed as a one minute call to the receiving system's location at late hour long distance rates. Replies are paid for by the reply sender. No profit is allowed to sysops for this service when users are charged for the service. All NetMail is sent at least nightly during Zone Mail Hour. This is a synchronized event taking place from coast to coast every day of the week. In addition, some systems allow sending and receiving of messages 24 hours a day, even during the higher priced daytime hours. This is known as CRASH MAIL, and is often sent as soon as it is posted by the sender. ECHOMAIL The method of sharing message boards between systems. This allows systems to share one or more message boards on a nationwide basis. Some are even worldwide systems. These shared boards are usually called ECHOS or ECHO CONFERENCES. These ECHO's are available for a wide variety of topics ranging from programming in Pascal to Amateur Radio. During the night, each system sends its day's messages from selected message areas to a central point and receives other system's day's messages in return. Distribution of echos is, as noted, almost always handled by a central system in each area to avoid confusion and possible duplication of messages. This service is usually provided by sysops at no charge to their users. An exception would be a board that charged for access for all or most services. Zone Mail Hour Participants in the Fido NetMail system are obliged to make their system available during Zone Mail Hour on a daily basis. This hour is synchronized to occur simultaneously across the country. 0100-0200 Pacific Standard Time 0200-0300 Mountain Standard Time 0300-0400 Central Standard Time 0400-0500 Eastern Standard Time Times are NOT adjusted for daylight savings time! In other words, if you were in the Pacific zone, your hour would be from 0100-0200 during standard time, and from 0200-0300 during daylight time if observed in your area. "OTHER" HOURS Your net may also observe other hours where your system needs to be available. Often, these times are used for EchoMail transfers. Note that sending EchoMail during Zone Mail Hour is a *usually* a no-no! You should avoid it unless it is acceptable in your area. Zone Mail Hour is usually reserved for NetMail transfers only, as large file transfers of EchoMail can tie up your system badly during this event. An example is that in the 104 (Denver) net, we once used the hours of 0100-0200 open for sending our EchoMail from the day to our central "collection points" - our EchoMail Hubs. From 0200-0300 we had Zone Mail Hour, and from 0300-0400 we received EchoMail from the coordinator. -3- ZONES, REGIONS, HOSTS (NETS), HUBS, NODES AND POINTS Each of these is descriptive of the position of a system in the overall network. Technically, every system in the Fido network is a NODE. A node is, after all, a "connection" within a system. However, certain nodes have responsibility for routing data between other nodes. ZONES are the largest discrete group of systems. There are now six FidoNet zones covering the world. One zone handles the U.S. & Canada, one for the Asian and Pacific areas, one for Europe and one for Latin America. Every node has an implied zone number (see Net/Node Number, below). Zone numbers are also sometimes used for interconnect to non-Fido networks. At this time, it is still common to find these other nets using non-Fido zone numbers (such as 8) to identify themselves. As Fido continues to add zones, this could someday present a problem, and new identificiation methods have already been established to handle this problem in a different way. We won't talk about this "DOMAIN" addressing technique here, but you should be aware of it. REGIONS identify a large geographical area within a zone. In the U.S. Zone, there are several regions, each taking care of a group of states. My region is 15 which takes in Colorado, Utah, Arizona, New Mexico and Wyoming. It's known as the Mountain Region. Region numbers are never used as part of a Net/Node number. However, be aware that your Net Coordinator's boss is the Regional Coordinator. He helps handle nodelist updates and the like, but isn't involved in the day-to-day moving of mail. HOSTS (also known as NETS) are the next smaller subdivision. Within Region 15, Denver is NET 104. On a typical Fido nodelist, you'll see these referred to as a HOST, we call them NETS. The person who administrates your net is known as the Net Coordinator. This is the person who is responsible for making sure that the current Nodelist (the FidoNet "phone book", so to speak) and other important items are made available to you. The Net Coordinator also assigns the node numbers (see below) in your net area. HUBS serve to distribute to a smaller geographic area. For example, as part of the Denver Net (104), various suburbs and surrounding cities are grouped around a Hub. My Hub is Boulder. These are never included in Net/Node numbers. Not all nets make use of hubs for assistance. NODES are the last step in the chain (but remember that actually, ALL systems are Nodes). Each system has a unique Node number within its Host or Net area. POINTS are like "superusers". They use mailer software to receive mail from a member of the network, and do not have their own node numbers listed in the nodelist. However, they do have unpublished private net (Point Net) numbers which are used to handle movement of mail between their systems and their respective Boss Nodes. Point Net numbers can be received by applying to your Zone Coordinator at 1/0. The ZC will supply you with your private net number, and you can assign the node portion of the number to systems as you see fit. NET/NODE NUMBER - the mailing address that makes it all work. In fact, the proper definition is ZONE:NET/NODE, but unless international or inter-net transactions are occuring the Zone number typically defaults in software to whatever your own Zone is. -4- Since I am in the U.S., Denver area, my number will be 1:104/something. My node number within 104 is 114, so my full address is 1:104/114. As noted above, the Zone is often ignored, so I'm 104/114 for short. Remember that Regions and Hubs are used for administrative purposes, and don't figure into your net/node address number. MESSAGE Of course, the primary purpose of all this is to move "messages" around the system between nodes. There are several types of message, and each is handled in a unique way by your software. We've already covered the definitions of EchoMail and NetMail messages above. There are several other types of "messages" as well, including the File Attach message and the File Request message. We'll touch on those a bit later in this file. Most often, your software will operate initially on the message with a filename in the form of *.MSG. A rare few systems avoid this intermediate stage and place the messages directly into the message base if there is a "database" style message base in use. Messages can be sent with a variety of attributes, some of which are FidoNet standards, and some of which are unique to particular software or groups of software. A few of these attributes include Private - Various software can be configured to handle this in a wide variety of ways. In many cases, only the sysop, the sender, and the receiver are made capable of reading a "private" message. Since the point of an echo is to move useful mail to a great many systems, sending a "private" message in an echo is tacky. Hundreds of systems may be forced to receive a message that their users can never read. Crash - Flags that this message is to be sent "crash". On many systems, the configuration causes a "crash" message to be sent immediately to its destination either directly or via whatever appropriate routing has been supplied. Hold - A message with a "hold" flag on it must generally be picked up by a call *from* the destination system. Kill/Sent - Most often used only on NetMail messages, this flags your software to delete your message once it has been packed or sent to the destination, avoiding cluttering up your own message area with traffic that has already been sent on its way. PACKET The most BASIC unit of transfer between two systems is NOT the message, it is the "packet". A packet is prepared by your software that contains all of the messages destined for a given system - all in one tidy bundle. There is no compression technique used here, only the bundling process takes place. When two systems make contact, and if things are configured properly, they will exchange any packets destined for each other. If you have four messages destined for a node, they will be transferred in a single packet during the connect. They are immediately broken down into "messages" by your software, and inspected for potential file requests or attaches. Regular messages are then processed in whatever fashion your software is designed to use to get the messages to someplace where they can be read. If you should ever spot a file whose name is in the form *.PKT, that's a packet. Note that when we discuss moving archived (compressed) mail files back and forth later, that it is the packets (*.PKT files) that are compressed. The FidoNet standard for this is the old SEA 5.X ARC standard, although many systems will use the newer ZIP format - but ONLY where mutually agreed upon in advance. -5- There are official FidoNet Technical Standards covering the exact construction of both messages and packets. Your software was most probably written correctly, and will conform to these basic formats. If, however, your software is prone to deviating from those standards, you're likely going to run into trouble with your fellow net members when *their* software gags and pukes on undecipherable messages or packets. It is *your* responsibility to remedy such situations when they occur. Always stay abreast of modifications and bug fixes for your software that are intended to enable your software to maintain FidoNet standard operation. If questions arise, the FTS standards are the final authority for such matters. If you're interested in seeing just how these standards allow your system to talk to others, you may want to locate and download these standards as created by the FidoNet Technical Standards Committee (FTSC). A great deal more thought has gone into making our systems function well together than first meets the eye! FIDONEWS Each week, more or less along with the new NODEDIFF file (the update to our FidoNet "phone book"), you'll receive the Fido News. The Fido News is a collection of editorial material, rants and raves, amusing stories, and a useful list of the latest known revisions for much of the software used by FidoNet systems. Announcements of events of interest to members is also included. Traditionally (well, let's say up until August 1990), the Fido News was transmitted in archived (ARC) format. The editor decided it would be amusing to begin transmission in LHARC (LZH) format in August of 1990, to the consternation of the many FidoNet members who have no utilities to turn the LHARC files back into readable text. Your Net Coordinator or Administrative Hub may recreate these files as ARC files, or may pass them through to you as LHARC files. If your computer has no LHARC utility available for it, you should request that it be converted before it is sent to you. I suspect that if enough such requests are made, the Net Coordinators will demand a return to a format for which decompression software is more readily available. Time will tell. -6- FIDONET POLICY FidoNet sysops are obliged to operate by a set of Policy guidelines that must be followed by all within the FidoNet system. If you plan to enter into the system, you should get a copy of whichever is currently available (4 is in current today) and read it. Most important are the understanding of Zone Mail Hour (above) and the responsibilities of the individual Sysop. Pay particular attention to what is known as an "annoyance". Fido is reasonably tolerant of a lot of things, but Major Annoyances can get you canned from the system. The policy also explains the responsibilities of the folks up the chain from you, and therefore explains what you can and cannot reasonably expect from them. Note that there is also an Echo Policy floating around. Sadly it doesn't define much in regard to data formats or archiving utilities or any number of other helpful things. However, it explains the duties of echo coordinators and hubs and what you may and may not expect of them. Much of the echo policy within a net is determined locally by the net members. At the time of writing, no EchoPol has ever been formally adopted by FidoNet as a whole. In addition, your net may have its own policy. In addition, your own net may adopt local policies detailing its own preferred method of operation so long as it does not come into conflict with FidoNet policy. Now for some other terms related directly to your software and its use: EVENT An Event is pretty much what it sounds like. It is an action that is taken at a specific time of day or within a range of times by your computer. You will want to set up Events so that at the appointed time, your system will begin to execute each Event. All you'll need to supply is the time and a description of what you want accomplished. An example of this would be to tell your mailer software that at 0200 it needs to put itself into send/receive mode for NetMail. NODELIST All of the addresses for the over 7,500 systems are contained in a file called the Nodelist. This file is updated on a weekly basis by the Fido coodinators. In addition, for those that already have the most recent large working file, small update files are made available weekly to add to the existing file. This avoids having to shuffle around the big one once a week to all systems. The large file is distributed as NODELIST.Axx, where xx represents the number of the distribution. This number is the day of year. The .Axx extension indicates that the file has been archived using SEA or PK or similar archive techniques. After un-ARC'ing the file, it will look something like NODELIST.241 instead of NODELIST.A41. You don't see the entire day, of course, until you un-ARC the file. The list is not useable by most software packages in its form as distributed. This list will likely need to be translated to operate with your mailer package. In addition, an index and some other necessary files are usually created from NODELIST.xxx. If you will be running software that can handle SEAdog, Opus or Fido style nodelist compilations, I strongly recommend use of XLAXNODE for your nodelist compiler. In addition to the NODELIST.Axx files, you will receive NODEDIFF.Axx files weekly. These are the changes rather than the entire list. These can be incorporated using XLAXDIFF. NODEDIFF.Axx files have the same extension (archive indicator + day number) as the larger files. -7- It's much faster to incorporate changes into your existing list than to receive an entire list each week! You'll discover that the archived version of the full list runs well over 300K! Execution of XLAX is a piece of cake. Just get yourself into the directory where XLAX and your node lists reside, and type XLAXNODE. You'll discover that it asks you to repeat a number that it gives you. This was the author's way of trying to convince you that you should register your copy and sent him his $10. Without doing so, you won't be able to run the program automatically in unattended mode. Send him his $10. It's a bargain! Note: due to some overlap between some European and U.S. node numbers, and the Zone-Brain-Dead nature of some mailer & BBS software, you may see some "duplicate" warnings as the node list is being compiled. This is normal. However, you should see pretty much the same ones month after month. If new ones start showing up, your list may be hosed. If you need to access these European nets, you may have to redefine them somehow. The NET command can be used in your XLAXNODE.CTL file to redefine duplicated net numbers. For example, if I have both a European and U.S. Net 237, I could redefine the European net number like this: NET 2:237 2237 By doing this, I can send a message to net "2237" and the call will be placed to 2:237. This does cause some complications for the receiving end, but if you wish to direct route mail to one of these "duplicate nodes", I know of no other way to accomplish it given the current problems with some of the BBS and mailer software out there that is not "zone aware". A couple of files are needed for compiling any nodelist. In the case of XLAXNODE, two of the more difficult to create are the file containing costs and the file containing corrections for dialing. I've chosen to call these COSTS.TXT and DIALFIX.TXT. The latter isn't too difficult, but you're going to either have to borrow the former, or do some substantial work to get accurate costs built into your nodelist if it needs them. COSTS The XLAX docs provide an excellent description of the format for this information. This list will probably the most time-consuming proposition in the entire setup unless you can get an accurate list from another sysop in your own local calling area. Best bet is to find the closest FidoNet sysop and rework that list as opposed to building one from scratch. One word of caution! If you use someone else's list, be aware that this person may be using a different long distance carrier, and that your rates may vary somewhat from his, even if you are in the same calling area. Getting rates from your carrier can be a real bitch. They HATE sending out rate lists for you in most cases. However, I've found that threatening to ask them by phone, area code by area code, often produces results. In general, rates don't vary much in the 1am-4am once you get outside a certain distance from your area, but be sure! International rates are a little easier to get in most cases. For in-state calls (where your local phone company has you by the cajones) [yeah, sexist remark], the possibilities may be endless and may require that you do some random sampling and just generate an average in order to avoid a list that could take weeks to enter. Of course, it should come as no surprise that in-state calls wind up costing more than long distance. You'll get an education into the cost of phone calls and federal regulation of interstate long distance as you go about this process! -8- Be sure that you enter the default domestic and international rates at the top of the list per the XLAX docs just in case your list misses something along the way! DIALING FIXES All of the entries in the node list are in the full length form. For example, a Colorado number might appear as 1-303-123-4567. If you live in Colorado, dialing 1-303- before every number gets you a recording telling you that you really didn't need to do that. In fact, you don't even need the 1- for calls in your local calling area. This file is where these things are dealt with. XLAX docs this well, as usual, but here's a couple of examples: I live in area code 303. One of my long distance 303 nodes is at 1-303-555-1111. In addition, two of my local calling area prefixes are 552-xxxx and 553-xxxx. I would want to include the following in my DIALFIX.TXT file: 1-303-555 1-555 (strip off the 1-303 when dialing, and use a 1-) 1-303-552 552 (strip off the 1-303 when dialing) 1-303-553 553 (strip off the 1-303 when dialing) etc., etc. NODELIST ENTRIES Everyone in FidoNet should be familiar with the makeup of a nodelist entry. Here is mine (split into two lines for convenience - they are never split in the list). ,114,The_Dinosaur_Board,Niwot_CO,Chris_Anderson,1-303-652-3595,9600, HST,V32,CM,XP Most of this information requires no explanation. The first number is my node number within Net 104. The second bit of information is the name of my BBS. Note that underscores are always used in the nodelist entry, but are generally converted to spaces by other software. The next items are my location, and my name. The phone number is "normalized" to include all of the dialing information required for somebody in the U.S. to place the call to my number. For those that are in my area code (303), their nodelist compiler must remove the 1-303 if they are a local call, and the -303 if they are not a local call. Next, the baud rate. -9- The baud rate is a little hinky. You may have a modem that can make a zillion (ok, only 14400) connect to my modem. But we leave THAT to the modems involved. 9600 is the highest baud rate that is reflected in the node list. A call placed by an HST modem to my system would indeed connect at the higher rate if the software was configured properly to do so. What follows the baud rate varies a great deal based on the system configuration and the diligence of the local net coordinator. These are called the FLAG information. For a system running 9600 or faster, there must be a flag that indicates the modem type in use. The combination of HST and V.32 connect possibilities are indicated because I am using a Courier HST Dual Standard that supports both. Last, we have the mailer software type. In my case, this is SEAdog, and the XP flag provides that information. Last, you should understand the CM, #09 and MO flags. The CM identifies a system able to receive mail (a 'crash' system) on a 24 hour basis. The #09 indicates that the system is not a CM system, but supports the Zone 1 (North American) zone mail hour at 0900 hours Greenwich (Zulu, CUT, or whatever you prefer to call it). A system with an MO flag is "Mail Only", and calling it with normal comm software will get you nowhere, as there is only a FidoNet mailer there - no BBS. I strongly recommend that you have a look at the end of the nodelist and find there a text section explaining the meaning of all of the other possible flags. You should also be aware that some NC's and hubs aren't very diligent about getting the right flags into the list (with the exception of the #CM flag). You should check your own entry to be sure it is correct in the nodelist. A program like LIST.COM is a handy way to do this, using the <F>ind feature. Just search for Host,xxx where the xxx is your net's number. Just below that, you'll find your own entry. You may see a couple of "oddball" entries in the Nodelist. First, there is the "Down" entry. This means that although the system may still exist, it is either down due to technical or other troubles, or the NC has been unable to communicate with it for unknown reasons. Failure to be available for NetMail by your NC during Zone Mail Hour may get you a "Down" notation in the list. Continued failure to be available for contact during ZMH may cause the NC to remove your entry from the list! Also, there is the "PVT", or Private node. There are a few folks out there that either don't want calls from anyone except their NC or hub, or are running software that most other systems couldn't connect with in the first place. These are discouraged, but when included in the list, they are marked as PVT and their phone numbers are generally unpublished in the list. The reason for their inclusion is to allow you to know how to route mail to them via their NC or hub. Yes, it's possible (and also common) to deliver NetMail to one system by sending it to another for re-routing. We'll cover this elsewhere. -10- FILE REQUESTS, FILE ATTACHES and other neat stuff Besides the normal traffic of NetMail, EchoMail and the like, a typical mailer system has a few more tricks up its sleeve that you may find very useful. One such feature is the File Attach Message. Although it is often used to move a bundled up file of EchoMail, the File Attach Message can be used to send a copy of any file between systems. When you get your weekly copy of your NODEDIFF file from your Net Coordinator or Hub, it is done by creating a special kind of message whose subject is actually the path and name of a file. There is a special bit set in order to do so - you can't just place a fully qualified path\file name in the subject area and cause the file to be sent. Either your mailer, message editor or BBS software will have the ability or come with a utility that provides the file attach function. This is not only a nice way to move FidoNews, the NODEDIFF files, and other administrative items, but can be used between two nodes to send out a new piece of interesting software, a copy of some config file that needs debugging - whatever sort of file you wish to send. Besides the File Attach Message, there is the File Request Message. Sometimes, in order to abbreviate File Request, folks will use the form " freq " or " f'req " instead. You'll often see someone talking about freq'ing a file. This is the File Request. As for the File Attach, one of your programs or associated utilities will provide you the ability to create a File Request Message. During any event that allows you to place a call to the system for which you've set up a File Attach or File Request Message, your mailer system will dial that system, and use the message to indicate to the other system that a file transfer is desired. So long as the other system hasn't included something like NO-FILES in the event, and as long as the other system talks the same "language" as yours, the file transfer will occur. One word of warning about File Requests... The FidoNet standards for such file transfers were cleaned up in late 1989/early 1990. Two internal protocols for handling such file transfers exist and are in common use in FidoNet. Both are valid, although not all systems support both methods. In fact, CERTAIN authors have still, as of this date (October 1990), refused to support one or the other of the standards. Alas, there are politics in Fido, Martha, and you should be aware that of this date, two mailers in particular have taken a path that makes them completely incompatible with the SEAlink protocol for file requests. One occurred by accident due to problems in interpreting what was once a vague standard, and seems to have given up trying. The other started out with similar problems, and then simply REFUSED to make any attempt at compatibility. They are, in order, Front Door and D'Bridge. If you are using either of these two mailers in what is, as of today, their currently supported versions, you can kiss file requests with SEAdog mailers goodbye. Both the "barefoot" Opus and Binkley mailers cover both standards, the Binkley mailer being the option for non-Opus-BBS users. If you are concerned about possible file transfers with a SEAdog mailer at any point in the future, Binkley may well be your best choice of a mailer. Ditto for using SEAdog. If you're concerned about transfers to Front Door, and ESPECIALLY D'Bridge mailers, SEAdog in its current form is going to present problems. Since rev 2.40 (+ mods) of Binkley, Bink and SEAdog are happily talking like crazy to one another. -11- ROUTING MAIL It's possible to send a message directly to any system with a published number in the Nodelist. This is due to the fact that all systems are required to observe the minimum FTS-001 (Fido Technical Standards) protocol that allows for the most basic mail packet to be transferred between systems. However, an alternative is to send the same message to the NC or hub of the destination node instead. Your mailer or "packing" software will allow you to send a message destined for a node to another system for re-transmission. It is ALWAYS acceptable to send mail routed to another node's Net Coordinator if, for whatever reason, you find any difficulty in connecting directly. However, it is considered tacky to route through another system without first obtaining permission from the other system. Moreover, it is entirely possible that another system won't have the proper routing installed to re-transmit your message to the destination in the first place! Except for NC or hub routing, ALWAYS ask first! ECHOMAIL, HOW IT WORKS Most of the traffic moved through FidoNet is in the form of what we call EchoMail. There are several other techniques for moving mail that are in use by other networks, but we'll stick to the EchoMail model for our purposes here. Again, a few definitions are going to be helpful: STAR SYSTEM / REGIONAL ECHO COORDINATOR There are a few selected systems across the U.S. that act as "stars" for FidoNet echomail. These systems supply cross-country connection between the various nets by accepting and distributing mail between each Region's primary system (often run by the Regional Echo Coordinator, or REC for short). In the case of some of the larger nets, they are connected directly to the "Star" systems, bypassing the Regional Coordinator due to the load of mail involved. It might look something like this (things tend to change frequently!), an abbreviation of the real star system in use: Western Star ------- MidWestern Star ------- Eastern Star / /|\ / /|\ /|\ / | | \ etc A large Net | | \ etc net is the 104 | | \ exception. / | \ / | \ / | | / | | / | | / | | Region Region Region 14 11 12 | etc | etc /|\ / | \ This is the more / | \ typical arrangement. / | \ Net Net Net 108 110 115 etc etc etc -12- Under the regions are typically the nets. Each net has its own primary system, usually run by the Net Echo Coordinator (NEC for short), who distributes the mail within the net. Often, the NEC appoints hubs to help in distribution of the mail. This is especially important in nets with a large number of systems and a large volume of EchoMail being imported. TAG LINE / ECHO TAG Each message in an echo area must include information regarding the specific echo to which the message belongs. This is placed at the top of the message before exporting to the outside world, and is used by all receiving systems to know in what message area the message needs to be placed on the BBS. It is also used for making copies of the message as needed (see below). This is called the Echo Tag, or Echo Tag Line. Most BBS software does not display this information, or strips it before placing the message in to the message base. How is this mess kept straight??? Messages flying all over creation and somehow, we manage to keep track of who needs to receive them and who's already seen them. Enter the SEEN-BY line, and another piece of useful information, the PATH line. Although not used to figure out where things need to go, it is easier to explain the whole procedure if we start with the PATH information attached to each message as it travels its course. The PATH is simply the list of systems through which any message has passed to get from its originating system to the destination system. Since messages will take different paths to reach different systems, each sees a slightly different PATH line when the message is delivered. Let's say, for example, that there are three systems that all share mail between them (a radically simplified model of the real distribution system shown above). Let's call these systems 100/1, 100/2, 100/3 100/4 and 100/5. Let us further assume that 100/2 is handling all of the distribution for mail between the three systems. In other words, all mail must pass through 100/2, regardless of where it originates, and is then passed on to the other two systems. In addition, we will assume that 100/3 is 'hubbing' for 100/4 and 100/5. The real topology of our "mini-net" would look like this: 100/2 / \ / \ 100/1 100/3 / \ / \ 100/5 100/4 -13- A message from 100/1 that is shared by all other systems would pass to 100/2 first, then to 100/3 and on to 100/4 and 100/5. The PATH information will always show how the message got to where it finally was posted on any system. For example, the message from 100/1 shows only 100/1 on the PATH line of the message as it leaves 100/1 bound for 100/2. The 100/2 is then attached before the message is routed on to 100/3. The 100/3 is then attached to the message before it is forwarded to 100/4 and 100/5. At 100/5, then, the path information should look like this: PATH 100/1 100/2 100/3 100/5 This is often abbreviated by software, making the assumption that if no net number is provided, it is assumed to be the same as the last listed net. In this (the most common) case, the PATH information would include our net number only once (since no others are involved in this message) and would simply be PATH 100/1 2 3 5 If a message were originated at 100/2, the path at 100/4 would appear as PATH 100/2 3 4 and at 100/1, it would simply be PATH 100/2 1 Where multiple nets are shown, paths might look like this: PATH 100/1 2 13/1 104/1 115 114 This shows that a message was passed up from 100/1 to another node (2) in that net, on to a net 130 system, to net 104, and down through a couple of nodes in net 104 to the final destination of 104/114. The next item of importance is the SEEN-BY line(s). This information is used by each system along the PATH to determine who has seen the message, and for whom copies need to be made. As a message is processed by any system, SEEN-BYs are added for any systems for which a copy is made by the processing system. Using our 5 node example above, a message moving from 104/1 to 104/5 would function this way: Message as sent from 100/1 SEEN-BY 100/1 2 Message as sent from 100/2 SEEN-BY 100/1 2 3 Message as sent from 100/3 SEEN-BY 100/1 2 3 4 5 Note that since 100/3 needs to make copies for both 100/4 and 100/5, it adds the SEEN-BY for both nodes for which it has made copies. Each system should provide itself in the SEEN-BY information when it is the originating system. Why? If it did not do so, the next system that received the message would send a copy back! The method of deciding who should be receiving copies is usually one format or another of a copies called AREAS.* Various software packages like to see this file in slightly different formats, but the essential information there is the echo tag with the list of nodes for which that system is responsible for making copies. -14- So, to wrap it up, the PATH shows how the message got from the originator to anyone receiving the message, and the SEEN-BY shows what systems copies were made for along the way. Checking for the sources of duplicate messages is simplified by the PATH information. By observing the two (or more) paths that the message may have taken to get to the destination, it is often easy to tell who has been sending the message to the wrong system(s), or fouling up the SEEN-BY information along the way. Note that clobbering SEEN-BY information or by making it unreadable to some other system is guaranteed to create duplicate messages. Although the PATH line must always begin with a "Control A" (a hex 01), the SEEN-BY line should NEVER start with one of these. Many systems won't "see" the SEEN-BY information if the line(s) start out that way! ORIGIN LINE The origin line can be used by the sysop to provide any information that helps identify the system that is originating the message. This information always starts with a '*' and a space, and is typically followed by the name and phone number of the originating system. There are some sysops who also include a cute saying here, and this is generally accepted, but beware of including messages with "political content", as it is appended to every message a user generates in an echo, and that user will not see the origin line after entering the message! User's have been known to become hostile when their messages are suffixed with things they're not in agreement with! Do NOT include your net/node number in the origin line if your software will add this automatically. All too often, new sysops add this to the origin line info, only to discover it is being duplicated by the software. Also, please note that much software won't display an origin line of >80 characters total, so remember that when you create your message, space must be left for the net/node and "* Origin" information! TEAR LINE This line starts with a '---' and is appended by either the message editor/BBS software, the packer or the mailer. Some software will delete any previously entered information and replace it with its own as your message passes between your various programs. Here's the "readable" portion of an EchoMail message, including a couple of items we haven't yet discussed (note that not all software allows the viewing of these items, even though they exist in the message). The control A (01hex) character will be represented by a "^" so that you can see where it would appear in the message. ECHO: ECHONAME ^EID: eid info ^MSGID: msgid info Text of the Message * Origin: Origin line information (zone:net/node) --- tear line information SEEN-BY seenby nodes list SEEN-BY continuation of list if required ^PATH path information -15- The EID and MSGID information is designed to help your software check for duplicate messages. Most times, this is simply a check sum of the body of the message, often including the header information (TO:, FROM:, etc.) When quoting any message with a message editor, it is important that you not accidently leave any of the EID, MSGID, SEEN-BY or PATH information resident in the message without something to preface it that would keep software from recognizing it. For example, if you have a need to quote the PATH information, be sure to delete the little smiley-face that appears for the 01hex, and stuff something in front of it (such as a ">") just to be safe! CROSS-LINKS As you can imagine, a fouled up SEEN-BY line or two in a message can cause a great number of duplicate messages to be created. Unless a system using the EchoMail technique described above has the full necessary SEEN-BY information, a system is likely to start generating copies for people that should have been listed, but aren't. Broken software can be a real pain here! There IS an exception to this rule, and when used, it must be used VERY carefully to avoid duplicates! This is the Cross-Link method of moving mail. Rather than dropping down the normal tier of nodes, the cross-linked mail message is transmitted "across" a number of hub nodes of equal position within the structure. This is used to avoid having to move mail up and back from the top level system in any structure. Things move a bit faster this way. Let's say that we have those old 100 series systems again, each *normally* being served their daily doses of mail via the Net Echo Coordinator at 100/1. regional or star feed | 100/1 | | /|\ / | \ / | \ / | \ / | \ / | \ 100/2 100/3 100/4 / | \ / | \ / | \ to other nodes served Normally 100/2, 100/3 and 100/4 would only send EchoMail between the nodes they serve as hubs and 100/1, the Net Echo Coordinator as in the diagram above. However, for those echos that are "Cross-Linked", this first tier of hub systems are ALSO "cross-linked" to each other! -16- regional or star feed | 100/1 | | /|\ / | \ / | \ / | \ //---^---\\ // | \\ 100/2--100/3--100/4 / | \ / | \ / | \ to other nodes served When a message appears on 100/2 that is originated on 100/2 or one of the nodes it serves, where the echo in question has been declared a cross-linked echo, 100/2 will immediately make copies not only for any of the nodes it serves, but also for 100/1, 100/3 and 100/4. This makes it unnecessary to first move the message back up to 100/1, wait until 100/1 unpacks and creates copies for 100/3 and 100/4, and can make contact with these other two top tier systems. This is CAREFULLY controlled (until someone screws up!) by making sure that all other top level systems are included in the AREAS file of each top level system. In the case of 100/2, the AREAS entry for a cross-linked echo in the system shown above would appear as follows: 100/1 100/3 100/4 100/xxx 100/xxx (where xxx are the other nodes that 100/2 hubs for). A fouled up AREAS file on the part of ANY of the systems that play a direct part in the cross-link will cause duplicates to be created quickly. Picture this: 100/2 forgets to include 100/1 in his AREAS file. When 100/3 and 100/4 see the message, they'll BOTH see that 100/1 isn't in the SEEN-BY information, and BOTH of them will make copies for 100/1. Bummer.. don't let it happen to you!!! -17- There are numerous utilities in use out there for handling the archiving and unarchiving of mail files. For SEAdog users, ARCMAIL (in one of its various revisions) is often used. Users of other BBS and mailer systems use this or other utilities. Problem: Not all utilities are flexible about the file name extension used for archived mail files. Not all systems can accept all extension variations! Your mail files *may* not be unpacked by the receiver under certain circumstances! Problem: Some of the utilities used on other systems will create packets improperly, generating "short packets". File extensions: Currently the following have been noted as file name extensions that are being generated by various utilities: A) FILENAME.ddn dd="MO" (never changes) n=sequential number B) FILENAME.ddn dd=day of week (SU, MO, TU, WE etc.) n=sequential number C) FILENAME.ddx dd=day of week (SU, MO, TU, WE etc.) n=sequential number/letter depending on the half hour of the day during packing (i.e., it will be 0-9 or A-Z depending on the time of day) D) FILENAME.xxx xxx=minute of the month in base 36 (using 0-9 and A-Z in all three positions) Don't be surprised if the FILENAME.ddn formats don't follow the actual day of the week. Some just cycle through 10 digits in the 'n' position and then begin the next day regardless of the day of the week when the file is created. Formats A,B and C seem acceptable to most systems. This comes from observing the experiences of the wide variety of software in use in Net 104. IF you are in contact with a system that generates the infamous "short packets" in archived mail files sent to you, note that some utils will choke on these, and you will be unable to extract your mail from them! Contrary to the comments of some, these short packets are NOT properly built according to FTS (FidoNet Technical Standards) format! -18- HOW ARCHIVE FILES ARE NAMED (apart from the extension, which we've already discussed): Incoming and outgoing archived mail files use the following method for the root portion of the name: NNNNnnnn.ext NNNN=sender's net number - receiver's net number nnnn=sender's node number - receiver's node number In both cases, the result is always expressed in 4 hexidecimal digits. Example: I am node 104/114. I am having mail transfers with node 363/18. If I send an archived bundle to 363/18, the result will be: 104-363 114-18 = -259 96 decimal = FEFD 0060 hexidecimal = FEFD0060.ext filename If 363/18 sends something to me, on the other hand: 363-104 18-114 = 259 -96 decimal = 0103 FFA0 hexidecimal = 0103FFA0.ext filename Both archiving and mailer software make use of this convention to determine where things are headed for. However, if both incoming and outbound files are present in the same directory, there can be some confusion! AVOID THIS! The REAL problem is where both result in valid node numbers! I got caught by this problem when working with node 104/115. Mail he would send me would look like mail *destined* for 104/113. If I didn't take time to unarchive incoming mail for 104/115, it would be forwarded to 104/113! Watch for this, as neither archivers nor mailers really know which direction things are headed! How did this happen? 104-104 115-114 = 0 1 decimal = 0000 0001 hexidecimal = 00000001.ext filename Now, if this were an incoming file, it would be correctly interpreted as a file *coming* from 104/115. But what if the mailer was asked to deal with an outbound file instead? You'd get the following! 104-104 114-113 = 0 1 decimal = 0000 0001 hexidecimal = 00000001.ext filename -19- Well, you can see that an incoming file called 00000001.ext means it is arriving from 104/115, but an *outbound* file to 104/113 has the same exact name! Since archivers and mailers use your net number as you've described it in some configuration file for these computations... well, you can see how you can get in hot water in a hurry. The fellow at 104/113 and I suffered through several days of this before the obvious occured to me. Don't leave someone else as confused as I did. THE SOLUTION TO ALL OF THIS IS TO AVOID PLACING INCOMING "FILES" AND OUTGOING "MAIL" (INCLUDING FILES) IN THE SAME DIRECTORY!!! Use different directories by specifying them differently in the configuration file used by your software. -20- How to Apply for a FidoNet Node Number Although written specifically regarding FidoNet procedures, you'll find that much of the information here in 101WAYS is applicable to beginning on any amateur network. The same is true for the process of obtaining and using your own node number. First, you'll need to locate the Net Coordinator (sometimes known as the NC) for the net you want to join. In the case of FidoNet and some others, it is preferred that you join the net nearest your physical location unless there is a substantial reason (long distance to nearest hub, etc.) that makes it financially more reasonable to go outside your local area. In order to find the NC, just locate any bulletin board in your area that supports FidoNet (or your choice of another network). You'll want to talk the local sysop out of a copy of the current Nodelist either via disk or download. Quite a few network sysops make these lists available for download. Next, you'll need to create a message with your software to the NC who will always be the /0 node of any network. For example, let's say that you local or nearest network is #104. You'd send your application for a node number to 104/0. During the time until you receive an official number, use something like node number 999 or 9999 to send your request. The request should include at least the following information: Your name and voice phone # The name and location of your board The phone number of your board Hours of operation Whether or not you are able to handle continuous (crash) mail Baud rates supported [if 9600+, please include which version(s)] Which mailer software you are using Each of these items is important as all but your voice phone # are required items for your own Nodelist entry. After sending your request, you should be available for a NetMail response from the NC during the hours you've specified for your system. He will return with your net/node address. Don't forget that people take vacations and the like, so be patient. However, it should NEVER take more than three weeks to get your node number. If it does, follow up with another message and perhaps a voice call. -21- SECURITY ISSUES FidoNet mailers most often make available the feature of the "session password". Any two systems may agree in advance on a particular password, and install it on their systems. Let's say that system 104/A and 104/B agree and install a password (the same password would be used on both systems). If 104/A calls 104/B, the mailer software makes notices that a password is being used when calling 104/B, and presents it's password to 104/B. If 104/B finds that the password exists in its own list, it continues the session. Note that 104/A doesn't ask for a password, as it assumes that since *it* dialed the call, the system on the other end is the real one! If some other system comes calling under the guise of 104/A, and is unable to provide the mutually agreed upon password, 104/B will hang up on this intruder - no file transfers of data will take place. Of course, this would also occur if one or the other systems accidently installed the wrong password, or no password for the other system. Obviously, both systems must agree and continue to employ a password for any transfers to take place. Why? Well, there are some naughty boys and girls out there who'd like nothing better than to create problems for someone - often just for the sake of doing so. The session password guarantees that when someone comes calling to deliver and pick up mail that they really are who they claim to be... simple as that. In Net 104, we have a local net sysop's echo. One of the rules established by the echo moderator is that in order to participate in the echo, all transfers to or from another system of the echo must be done within the confines of "session passworded" sessions. This provides our net with some degree of security, keeping some ne'er-do-well from gaining any insight into our private conversations regarding how we're operating the net, problems (and solutions) with users, etc. I STRONGLY recommend it for any system with which you will be regularly moving mail. Of course, it is impossible to establish session passwords with every system that might ever place a call to your system. That, in itself, represents a problem, but with a bit of manual effort on your part, this can be handled as well. -22- First, you should be aware that it is relatively easy to do ALL of the following on a good many netmail capable systems that have not been properly configured for good security protection: o Messages sent into echos that appear to be from you, on your system, that were sent by other persons. All path and seen-by information is perfect, and, in fact, the message is sent by your system without anyone logging on to your system. If you have session passwording between you and your echo hub, all the better, as the message will pass straight through into the echo via that path! You may never see the message posted on your own system, however! o Files sent by your system to another system. Can be anything that the user of the other system can correctly identify a path for, regardless of whether or not you have set that path up for file requests. o Destruction of your inbound echomail or netmail archive files if you have not yet processed them. o Bad NODEDIFF files - one clever thought was to change the phone number of a sysop's echo hub to the sysop's own home voice telephone number. In another case, one 15 year old changed many numbers in the net to 911. You can imagine the problems this caused with emergency services. o A wide variety of other nasty things, including having your system make expensive 976- calls, forward mail to Norway... you name it. These things are possible due to the fact that many sysops ordinarily un'ARC archived NetMail files without manually reviewing their contents. I won't go into the techniques involved in causing any of the above, but suffice it to say, it is a relatively easy matter to do these things, and I have tested most of them in cooperation with other systems in my net. So, how do you protect yourself? The sysop has only one recourse against such bad behavior... and by the way, it doesn't require another Fido sysop to accomplish this ... anyone with a working knowledge of some mailer software and a nodelist could probably accomplish what I've outlined. No, it isn't session passwording, although that is essential in order to make the technique described work. This technique allows you to automate unpacking and tossing of mail from your regular sources - if you use session passwords. It avoids automatic unpacking of potential 'trojan' netmail archives, and offers some measure of protection against them. The downside to this method is that incoming netmail must be moved to the secure directory and un'arc'd manually and inspected before you allow it to be posted to your system. This may cause some delays on incoming traffic for your users if you allow them access to netmail for their own use. CHECK YOUR SOFTWARE! If it allows multiple directories to be used for inbound archived mail files, USE THEM! You should only automatically unpack mail from those systems with which you regularly do business, and for which you have session passwords installed. ALL OTHER inbound archived mail should be shuttled off to a separate inbound file area and should be INSPECTED carefully before you move these inbound messages into the regular message area for processing. i INDEX Index to be created at Revision 1.0 (release) of this document).